[レポート] DEM82 – 価値ある険しい道のり: AWSでJIRAをクラウドネイティブにする #reinvent

こんにちは。池田です。本記事は現地時間2018/11/26-30で行われたre:Invent 2018のデモセッション DEM82 - The Hard Road Was Worth It: Making Jira Cloud-Native on AWS （意訳： 価値ある険しい道のり: AWS で JIRA をクラウドネイティブにする）という、クラスメソッドでも利用している Attlassian の JIRA に関するセッションレポートです。

概要

Join Jake Brereton, a five-year Jira veteran, as he discusses how and why Atlassian chose to fork the code base of its flagship product and spend two years completely rearchitecting Jira from the ground up. Learn how moving from Atlassian's own data centers to AWS enabled the Jira team to ship more value to users in a fraction of the time, all while increasing uptime, speed, and reliability. From monolith to microservices, the project management tool Jira Software has been completely reimagined for the future of software development. And we're just getting started. This presentation is brought to you by AWS partner, Atlassian.

登壇者

Jake Brereton , Attlassian

セッションレポート

最初は「24 months of Vertigo（めまいの24ヶ月）」として、JIRA を AWS ヘ移行したプロジェクトのお話でした。移行計画に12ヶ月、さらに12ヶ月かけて再構築を行った大規模な移行案件だったようです。

続いて非常に大規模な移行案件となった背景についての説明に移ります。
2002年から始まった JIRA と Confluence は2008年に JIRA studio がサードパーティのデータセンターを利用するかたちで開始しましたが、より大規模かつ拡張性の高いソリューションが必要となったため、独自の（自家製）データセンターを持つことを決定したそうです。
2012年、Unicorn と名付けたこのデータセンターへ全ての JIRA ユーザーが移行されました。その後2017年までの5年間で急速な成長を遂げ、JIRA をホストするサーバー数も急増したとのことです。

既に数百万人のユーザーを抱えた JIRA システムは、データセンターとクラウド側で共通のコードを利用していたため、僅かな修正や変更を行うにも大変な苦労があったようです。

順調にユーザーが増えていった結果、Unicorn は写真のように多くのユーザー用インスタンスと JVM プロセスを抱え、データセンターでは120ものラックを使用するまでの規模となっていたそうです。

その上でさらなる利便性や処理能力の向上などが求められるも、いよいよ自前のデータセンターでは柔軟な運用が難しくなってきたため、クラウドへの移行について検討を開始したそうです。それには次のような理由があったと説明されていました。

• エンジニアがこれ以上時間と労力を使い疲弊してしまわないために、数十万ものインスタンスや JVM プロセスの管理がしなくて済むサービスが必要
• ユーザーの増加に対して Unicorn では柔軟な対応が出来なかったスケーラビリティの向上とパフォーマンスの向上が必要
• ユーザーがより増加しても対応が可能なシステムとすることによるビジネスのさらなる成長をさせる

また、移行にあたり三つの原則を決めたとも紹介されていました。

• Transparency
  • 直訳すると透明度になりますが、クラウドへの移行を利用者に意識させずに実施したかったとのことです。特に JIRA をミッションクリティカルなものとして利用しているユーザーに配慮したかったと仰っていました。
• Functionality
  • 機能性。既にある機能は全て移行することが決定されました。これは JIRA の柔軟なカスタマイズ性が利用者のメリットであり、選ばれる理由だと判断したからとのことでした。
• Performance
  • 移行において僅かなパフォーマンスの低下も許されないという前提があり、それは前述の二つの原則を守るためだったと説明されていました。

セッション後半は、24ヶ月もの長期に渡った Atlassian 最大のプロジェクト JIRA の AWS 移行作業完了を迎えた後の話題でした。

• パフォーマンス関連のサポートチケットが75%削減された
• パフォーマンス関連のサポートチケットに費やす時間が77%削減された
• パフォーマンス専門のサポートチームの3/4が解放され、他のユーザーサポートに対応できるようになった
• MTTR（平均復旧時間）は数日から数分に短縮された
  • 320,000 もの JVM プロセスをリスタートさせる必要がなくなり、同時にデータセンターで大量のサーバーへ電源投入する際にブレーカーが落ちるなどの電力問題も心配する必要がなくなった

• Unicorn 時代は全てのサービスについて1日に1回のリリースだった
• AWS に移行してからはリリース速度が格段に向上した
  • 大規模なサービス向けに1日4回のリリースが可能
  • 小規模なサービス向けには1時間毎のリリースが可能となった
  • これはユーザー、顧客に対してより早くより高い価値を提供できるようになっただけでなく、エンジニアにとってもハッピーなことである
• 仮にリリースを行なった後に計画通り機能しない場合もスナップショットからのロールバックが容易になった

また、AWS の利点として、次のようなことを挙げていました。

• テスト（実験）がすぐに様々な方法で実行できる
  • Unicorn では実際にハードウェアを購入しないとできなかった、各種リソースやセッティングの正確な見積もり、計測を行うことが可能になった
  • 結果、微調整やチューニングが容易になり、ユーザーにとってもパフォーマンスが25%向上、issue の読み込み速度が40%向上するなどのメリットをもたらしている

おわりに

最後は JIRA の今後についての紹介でしたのでここでは割愛し、ここまでの話題と筆者の経験談を照らし合わせて少し考察をしてみようと思います。
Unicorn ほどの規模ではありませんでしたが、数千人規模のユーザーがいるオンプレミス環境を構築、運用、保守していた経験があります。そのためユーザーや負荷の増加にどう対応するかというスケールの問題、ハードウェア故障などの障害に対する備えにリプレイスの問題など、Unicorn を担当したエンジニアの苦労は少なからずわかるつもりです。
それらを全てクラウドへ移行したことも大変だったとのことですが、システムに必要なものを手に入れるための移行だったとも紹介されていました。クラウドへの移行は、その先にある様々なメリットがわかれば、そしてそのメリットと現状を維持するメリットを比較できれば、どちらがユーザーにとって良い選択になるのかビジネスとして最善であるのかが判断できると思います。
これは、規模ももちろん、そのシステムで何を提供しているのか、ビジネスにおける重要度なども関わってくるので答えは一つではないと思っています。例えば機密データ保護の観点から定められた社内規定や、各種法令の関係などでオンプレミスの継続が良いケースもあるでしょうし、条件によってはハイブリッド構成が良いケースもあるでしょう。
ただ、ユーザーへのより良いサービス提供を維持していく上では既存のシステムを見直し、クラウドを利用するメリットや利用できる可能性がないかを検討することはあっても良いのではないかと感じています。もしかすると今回の事例のようにクラウドが最適解となるかもしれません。

宣伝

クラウドの利用を検討したいけれど、どうしたら良いのかわからない。初めて利用するには色々不安...という場合は、お客様のAWSクラウド環境を総合支援する「クラスメソッドメンバーズ」へお気軽にご相談ください。